1. Field of the Invention
The present invention generally relates to electronic design automation (EDA). More particularly, the present invention relates to a coverification system and method for performing simulation, hardware acceleration, and coverification with target system and external I/O devices to verify electronic systems.
2. Description of Related Art
In general, electronic design automation (EDA) is a computer-based tool configured in various workstations to provide designers with automated or semi-automated tools for designing and verifying user""s custom circuit designs. EDA is generally used for creating, analyzing, and editing any electronic design for the purpose of simulation, emulation, prototyping, execution, or computing. EDA technology can also be used to develop systems (i.e., target systems) which will use the user-designed subsystem or component. The end result of EDA is a modified and enhanced design, typically in the form of discrete integrated circuits or printed circuit boards, that is an improvement over the original design while maintaining the spirit of the original design.
The value of software simulating a circuit design followed by hardware emulation is recognized in various industries that use and benefit from EDA technology. Nevertheless, current software simulation and hardware emulation/acceleration are cumbersome for the user because of the separate and independent nature of these processes. For example, the user may want to simulate or debug the circuit design using software simulation for part of the time, use those results and accelerate the simulation process using hardware models during other times, inspect various register and combinational logic values inside the circuit at select times, and return to software simulation at a later time, all in one debug/test session. Furthermore, as internal register and combinational logic values change as the simulation time advances, the user should be able to monitor these changes even if the changes are occurring in the hardware model during the hardware acceleration/emulation process.
Co-simulation arose out of a need to address some problems with the cumbersome nature of using two separate and independent processes of pure software simulation and pure hardware emulation/acceleration, and to make the overall system more user-friendly. However, co-simulators still have a number of drawbacks: (1) co-simulation systems require manual partitioning, (2) co-simulation uses two loosely coupled engines, (3) co-simulation speed is as slow as software simulation speed, and (4) co-simulation systems encounter race conditions.
First, partitioning between software and hardware is done manually, instead of automatically, further burdening the user. In essence, co-simulation requires the user to partition the design (starting with behavior level, then RTL, and then gate level) and to test the models themselves among the software and hardware at very large functional blocks. Such a constraint requires some degree of sophistication by the user.
Second, co-simulation systems utilize two loosely coupled and independent engines, which raise inter-engine synchronization, coordination, and flexibility issues. Co-simulation requires synchronization of two different verification enginesxe2x80x94software simulation and hardware emulation. Even though the software simulator side is coupled to the hardware accelerator side, only external pin-out data is available for inspection and loading. Values inside the modeled circuit at the register and combinational logic level are not available for easy inspection and downloading from one side to the other, limiting the utility of these co-simulator systems. Typically, the user may have to re-simulate the whole design if the user switches from software simulation to hardware acceleration and back. Thus, if the user wanted to switch between software simulation and hardware emulation/acceleration during a single debug session while being able to inspect register and combinational logic values, co-simulator systems do not provide this capability.
Third, co-simulation speed is as slow as simulation speed. Co-simulation requires synchronization of two different verification engines - software simulation and hardware emulation. Each of the engines has its own control mechanism for driving the simulation or emulation. This implies that the synchronization between the software and hardware pushes the overall performance to a speed that is as low as software simulation. The additional overhead to coordinate the operation of these two engines adds to the slow speed of co-simulation systems.
Fourth, co-simulation systems encounter set-up and hold time problems due to race conditions in the hardware logic element or hardware accelerator among clock signals. Co-simulators use hardware driven clocks, which may find themselves at the inputs to different logic elements at different times due to different wire line lengths. This raises the uncertainty level of evaluation results as some logic elements evaluate data at some time period and other logic elements evaluate data at different time periods, when these logic elements should be evaluating the data together.
In addition to these problems, the industry has not provided an effective way to provide simultaneous access to a simulation system for multiple users or multiple processes. Typically, only one workstation or process is coupled to a single simulation system.
Memory management is another problem in the industry. Existing simulation or emulation systems do not effectively address memory allocation/access issues. As known to those skilled in the art, the configured and mapped user""s designs are associated with many memory blocks in each FPGA chip. These memory blocks are located throughout and sporadically in each FPGA chip. When the computing environment (e.g., simulation software and central processing unit) needs to access a particular memory block, it must do so through a separate memory controller or look in each FPGA chip via its own memory controller. The memory access thus becomes too slow and cumbersome. Moreover, these simulation and emulation systems dedicate certain pins in each FPGA for memory access purposes. Thus, the dedicated pin systems waste limited chip pin and functional resources. Also, for numerous memory blocks in each FPGA chip, the memory access becomes awkward.
Existing FPGA board-to-motherboard connection schemes are also inadequate as space becomes a premium on motherboards and signal reliability becomes an issue more than ever. Because each FPGA chip has limited capacity, several FPGA chips and several FPGA boards holding several FPGA chips must be used to accommodate the large and complicated user circuit designs. As more boards are used space on the motherboard becomes an issue. If a single connector is used to couple one FPGA board to the motherboard, the number of FPGA boards that can be coupled to the motherboard is limited by the size of these connectors. Given the large size of these connectors, the density of FPGA boards on motherboards is severely restricted. Furthermore, when multiple connectors are used to couple one FPGA board to the motherboard, signal reliability becomes an issue. With more connectors arranged along any given signal path, the chances of signal attenuation and reflection increase, thus decreasing signal reliability. During shipping and handling of systems using multiple board-to-motherboard connectors, the vibrations resulting from the physical handling these systems may cause decoupling of certain connections. With such decoupling, the reliability of signals will be a concern; that is, while some signals reach their designated destinations, other signals may never get there due to severed signal paths.
Another problem associated with current board-to-motherboard connection schemes is that when a backplane is not available, all signals transmitted between these FPGA boards must be routed to the connectors on the motherboard first. Such a requirement adds to the signal trace length and increases delay during execution. An interconnect scheme must be provided to minimize such long signal trace lengths.
Existing coverification systems are also defective. A detailed explanation is necessary. In today""s fast-paced and competitive marketplace, the design and development cycle of an integrated circuit, logic circuit, embedded logic, or other circuit design (e.g., ASIC chip) should generally be as short as possible. Designing the design correctly the first time and developing it quickly are goals that every company strives to achieve to get the associated product to the market or else the product may fail for lack of timeliness. To accomplish this goal, the design must be correctly modeled at various layers of abstraction, designed with precision at lower levels, thoroughly tested via a combination of simulation, emulation, and co-verification, manufactured, and then tested again prior to market release. Although the marketing and manufacturing aspects of a product are out of the designer""s control, the design/verification cycle however can be shortened without any loss in quality. The need to shorten the time from initial design to a verified working ASIC chip is addressed by the present invention.
Currently, a design is designed and developed in two distinct stagesxe2x80x94design and verification. Although many times, a design can go from the verification stage back to the design stage if some bug or error has been detected. Designers use a number of development tools to aid them in these stages. These development tools provide the designers with an implemented model of the design in a development system prior to committing the design to a final implementation, such as an ASIC or a custom integrated circuit design. Such an implemented model in a development system is used for debugging the design and for developing target systems, which will use the design. Several methods for providing an implementation of the design in these stages are software simulation, hardware emulation, and coverification.
As discussed above, software simulation is used in the design stage. Simulation is primarily a front-end process which allows the designer to design, synthesize, and simulate the logical representation of their design without ever reducing the design to costly and time-consuming hardware form. The applied stimulus is artificial in nature consisting of digital signals and test vector patterns in software. One powerful aspect of software simulation is that internal states of the design can be obtained to facilitate the debug process.
Emulation, on the other hand, is used in the verification stage. Emulation is conventionally known as a back-end process of verifying the design in hardware form in its target environment. The applied stimulus is more comprehensive than that used for software simulation because the emulated design receives its test inputs from its target environment rather than some artificially generated source in software. Because the emulated design is in hardware form, the emulated design is operating at emulation speed that is much higher than software simulation speed although still slower than final implementation speed. However, the emulation can only inform the designer whether the design has passed or failed; that is, the emulation system will provide pin-out outputs in response to the applied stimuli from its target environment which may or may not be correct. The emulation system cannot provide internal states and values easily to further assist the designer in debugging the design.
In short, the designer can utilize software simulation in the design stage to constantly debug and re-design his design without ever incurring the cost of reducing his design to hardware form. Later, he can utilize hardware emulation in the verification stage to test the accuracy of his design in its natural target environment by reducing his design to some hardware emulation form to determine whether the design passed or failed.
Coverification is related to both simulation and emulation. If a system design contains both hardware and software components, coverification is used to test and debug both components. Coverification is becoming more and more important to designers as more and more system designs include a hardware design and a software design that runs on the hardware design. Furthermore, various industries are experiencing paradigm shifts in design/development methodology which attempts to bring verification tools earlier into the design process. However, existing coverification tools are significantly limited in supporting this new design/development methodology, as described below.
Currently, the hardware circuit and its associated software are designed and developed separately. After the initial high level modeling (usually behavioral modeling), hardware designers and software designers split ways and proceed with developing separate models and specifications; that is, the hardware designers develop a hardware model of the design and, in parallel, the software designers develop a software model that will run in the hardware design. When the hardware designers complete their initial hardware design and the software designers complete their initial software design that will run in the hardware design, they test their respective design""s performance with coverification tools.
Generally, two types of coverification tools are available today. One type of coverification tool uses the actual ASIC while the other type uses an emulator. Both present some problems for the designer. In the first type of coverification tool, the hardware designers have committed to an actual ASIC after running simulations with test bench data and emulation with target data. This ASIC is then provided to the software designers who test their software design on the ASIC. However, this coverification tool can only indicate whether the design xe2x80x9cpassedxe2x80x9d or xe2x80x9cfailedxe2x80x9d with no detailed information on internal states/values that may be useful for debug purposes. If the test indicates that the design xe2x80x9cfailed,xe2x80x9d the coverification tool cannot provide any useful information that tells the designer where the problem(s) or bug(s) is located; that is, the tool cannot inform the designer whether the bug(s) is in software, hardware, or any particular location inside the hardware. The test merely informs the designer that the ASIC xe2x80x9cpassedxe2x80x9d or xe2x80x9cfailed.xe2x80x9d The designer must utilize his knowledge of the design and some other sophisticated methods to isolate the problem(s). In any event, the designer must redesign and submit another order for the ASIC.
Waiting for the delivery of each ASIC for each xe2x80x9cfixxe2x80x9d of a bug is another problem. Although waiting for a single ASIC from the ASIC manufacturer can be predetermined and factored into the design/development schedule, the unpredictable nature of the design and re-design process to xe2x80x9cfixxe2x80x9d bugs complicates the design/development scheduling. If the design has too many bugs, a xe2x80x9cfixxe2x80x9d requires that the designers re-design the design and order another ASIC. When the ASIC arrives, the designers then test it and if it fails again, the designers have to re-design and order another ASIC. Each time that the ASIC fails a test, the designer must somehow isolate the bug(s), provide a xe2x80x9cfix,xe2x80x9d and re-order the ASIC again. This process of re-designing and re-ordering ASICs for further testing may continue indefinitely which adds further delay in the design/development cycle. Because the number of bugs and fixes thereof cannot adequately be determined at the outset of a project, this additional time cannot be accurately factored into the design/development schedule.
The cost associated with ordering the ASICs is another problem. Again, each ASIC cost can be factored into the design/development budget, but because the number of bugs and thus the number of xe2x80x9cfixesxe2x80x9d cannot be anticipated at the outset, the budgeting becomes more difficult. The cumulative cost of all the ASICs needed to finalize the design cannot be determined with accuracy. In addition to the difficulty of budgeting, the cost itself may be another issue. Depending on the complexity of the design, the cost of a single ASIC can be anywhere from a few thousand dollars to millions of dollars. As the number of xe2x80x9cfailsxe2x80x9d during a coverification test increases, the cost of re-ordering a xe2x80x9cfixxe2x80x9d in the form of an ASIC also increases.
Additionally, the segregated nature of the hardware and software design process slows down the design/development cycle, as the software designers must wait for the hardware designers to complete their design and verification process. Thus, the design/development cycle is further delayed in waiting for the ASIC order to be delivered from the ASIC manufacturer before the software designers can begin testing their software design on the hardware design.
In sum, this first type of coverification tool where an actual ASIC is used provides numerous problems for the design team. These problems include: (1) the lack of a flexible or useful debug feature (i.e., the designer cannot isolate the problem that resulted in the xe2x80x9cfailedxe2x80x9d test); (2) the unpredictable delay associated with the delivery of all of the ASICs needed for the cumulative xe2x80x9cfixesxe2x80x9d of the bug(s) because the number of bugs and hence the number of xe2x80x9cfixesxe2x80x9d cannot adequately be determined at the outset of a project; (3) the budgeting problem associated with ordering the ASICs because of the unpredictable nature of detecting and fixing bugs; (4) the cost associated with the purchase of all ASICs for all of the xe2x80x9cfixes;xe2x80x9d and (5) the segregated design methodology that forces the software designers to wait for the hardware designers.
Another type of coverification tool uses an emulator instead of the actual ASIC. However, this type of tool is limited in its debug capability. First and foremost, the emulator has its own clock and engine. Accordingly, it is free running and the designer cannot stop it easily. If the designer wants to examine internal states and values of his design cycle-by-cycle or event-by-event for part of his design, uses those results to accelerate to other test points, and then obtain other internal state information after this acceleration period to perform cycle-by-cycle simulation, the designer cannot do this with the emulator. The emulator is free-running with its own clock.
If internal state information of the user""s design is desired, the designer can use either a logic analyzer or a sample-and-hold device. Although more flexible than the coverification tool where an ASIC is used, the use of the logic analyzer or the sample-and-hold device can generally, although not effectively, be used to isolate the problem(s) or bug(s) of the design and can implement a xe2x80x9cfix.xe2x80x9d Aside from the fact that the logic analyzer is external to the emulator (and hence, it is usually used for designs of simple to medium complexity) and the sample-and-hold device is built into the emulator (and hence, it is usually used for designs of medium to high complexity), both devices allow the designer to sample various internal states and values, store them in memory, and then provide the data to the designer""s workstation for recall for later debugging. These devices must usually be running at a high enough speed so that the sampling can be useful. In some cases, the sampling rate must be 16 times faster than emulation speed. If the emulator uses a 10 MHz clock but the logic analyzer can run at 16 MHz, the designer must slow down the emulator speed to 1 MHz to have the requisite 16:1 ratio of logic analyzer sampling speed to emulator speed. Thus, the already slow emulator must be further slowed down, thus rendering an inflexible emulator into an even slower inflexible emulator.
Furthermore, both devices examine signals rather than data, which complicate the debug process in many respects. Because signals are used, the designer must first compile the emulator so that the relevant signals are provided on output pins so that the logic analyzer or sample-and-hold device can capture these relevant signals, convert them to data, and then store them for debug purposes later. If, during the debug session, the designer finds a bug in a particular area of his logic design, the designer must re-compile the emulator so that the area of the logic design that contains the bug can provide the relevant signals to the output pins. If further bugs are found later, the designer must re-compile again so that the portion of the logic design containing the bugs can provide the relevant signals to the output pins for sampling by the logic analyzer or the sample-and-hold device. Each re-compilation effort takes several days to weeks. The process of recompiling the emulator several times during the debug adds more delay to the design/development cycle. Designers need a coverification tool that does not need so much re-compilation time, or any re-compilation time at all for that matter.
An additional problem arising from the fact that these logic analyzers and sample-and-hold devices require signals rather than data is the numerous external wires necessary for the emulator. In some high complex designs, the emulator needs as many wires as signals so that the designer can debug effectively. Hundreds of output wires are not uncommon in some debug sessions. Designers need a coverification tool that does not need so many wires.
Moreover, the emulator system is burdened by the fact that because signals are used, additional complicated hardware is needed to convert these signals to data or control the timing of some signals with respect to other signals. In many instances, designers can debug effectively only if these signals are ultimately converted to data. Furthermore, these signals are only useful if their timing is strictly controlled with respect to other signals via buffering or other speed control so that the correct data will be obtained. These requirements force some complicated hardware set-up even before debugging can commence. Designers need a coverification tool that does not need these additional complicated hardware circuitry to adequately handle signals.
Recently, various industries are slowly experiencing a paradigm shift in the design/development process. The paradigm shift includes more emphasis on codesign where the hardware portion and software portion of a single system are designed and developed concurrently. Partitioning and re-partitioning of hardware and software tasks (i.e., determining boundaries for hardware and software designers) should occur constantly and forces the team of hardware and software designers to constantly consider hardware/software communication interface requirements at every level of the design. Although coverification is often thought of as happening later in the design cycle as discussed above, the new paradigm advocates starting the coverification process earlier and continuing throughout the design process.
Currently, designers adhere to the assumption that emulation, rapid prototyping, and very high-speed simulation are strictly verification tools. However, the new paradigm requires that these so-called verification tools can and should be used as design tools instead; that is, the designer has to pull emulation into the design process when considering what goes into hardware and what goes into software. If hardware/software coverification occurs before fabrication of the design as an ASIC, the hardware and software designers can interact with and analyze the same design at the same time without incurring the additional time and expense of the ASIC. The farther up the design/development chain that the designers can begin collaborating, the better and faster the design/development cycle. As various industries begin to see the value of bringing verification early into the design stage, the development tools must keep pace with these changes and provide tools that can work well in this new paradigm.
The coverification tool that the industry seeks must support the hardware-unaware software designer and the software-unaware hardware designer during the design stage so that they can work together on the system design and verification concurrently. Despite this paradigm shift, no prior art system has effectively allowed designers with such a powerful and flexible coverification tool that allows the software design to be simulated and verified on the hardware design prior to fabrication of the hardware design as an ASIC or with more flexibility than that provided by an emulator. Because 70% to 80% of verification time is spent conducting functional simulation, reducing this time will accelerate the design/development cycle significantly.
Accordingly, a need exists in the industry for a system or method that addresses problems raised by currently known simulation systems, hardware emulation systems, hardware accelerators, co-simulation, and coverification systems.
The present invention provides solutions to the aforementioned problems in the form of a flexible and fast simulation/emulation system, called herein as the xe2x80x9cSEmulation system,xe2x80x9d xe2x80x9cSEmulator system,xe2x80x9d or a Coverification system containing a Reconfigurable Computing System (or RCC computing system) and Reconfigurable Hardware Array (or RCC hardware array).
The SEmulation system and method of the present invention provide users the ability to turn their designs of electronic systems into software and hardware representations for simulation. Generally, the SEmulation system is a software-controlled emulator or a hardware-accelerated simulator and the methods used therein. Thus, pure software simulation is possible, but the simulation can also be accelerated through the use of the hardware model. Hardware acceleration is possible with software control for starting, stopping, asserting values, and inspecting values. In-circuit emulation mode is also available to test the user""s circuit design in the environment of the circuit""s target system. Again, software control is available.
At the core of the system is a software kernel that controls both the software and hardware models to provide greater run-time flexibility for the user by allowing the user to start, stop, assert values, inspect values, and switch among the various modes. The kernel controls the various modes by controlling data evaluation in the hardware via the enable inputs to the registers.
The SEmulation system and method, in accordance with the present invention, provide four modes of operation: (1) Software Simulation, (2) Simulation via Hardware Acceleration, (3) In-Circuit Emulation (ICE), and (4) Post-Simulation Analysis. At a high level, the present invention is embodied in each of the above four modes or various combinations of these modes as follows: (1) Software Simulation alone; (2) Simulation via Hardware Acceleration alone; (3) In-Circuit Emulation (ICE) alone; (4) Post-Simulation Analysis alone; (5) Software Simulation and Simulation via Hardware Acceleration; (6) Software Simulation and ICE; (7) Simulation via Hardware Acceleration and ICE; (8) Software Simulation, Simulation via Hardware Acceleration, and ICE; (9) Software Simulation and Post-Simulation Analysis; (10) Simulation via Hardware Acceleration and Post-Simulation Analysis; (11) Software Simulation, Simulation via Hardware Acceleration, and Post-Simulation Analysis; (12) ICE and Post-Simulation Analysis; (13) Software Simulation, ICE, Post-Simulation Analysis; (14) Simulation via Hardware Acceleration, ICE, Post-Simulation Analysis; and (15) Software Simulation, Simulation via Hardware Acceleration, ICE, and Post-Simulation Analysis. Other combinations are possible and within the scope of the present invention.
Each mode or combination of modes provides the following features or combinations of features: (1) Switching among modes, manually or automatically; (2) Usagexe2x80x94the user can switch among modes, and can start, stop, assert values, inspect values, and single-step cycle through the simulation or emulation process; (3) Compilation process to generate software models and hardware models; (4) Software kernel to control all modes with a main control loop that includes, in one embodiment, the steps of initialize system, evaluate active test-bench processes/components, evaluate clock components, detect clock edge, update registers and memories, propagate combinational components, advance simulation time, and continue the loop as long as active test-bench processes are present; (5) Component type analysis for generating hardware models; (6) mapping hardware models to reconfigurable boards through, in one embodiment, clustering, placement, and routing; (7) software clock set-up to avoid race conditions through, in one embodiment, gated clock logic analysis and gated data logic analysis; (8) software clock implementation through, in one embodiment, clock edge detection in the software model to trigger an enable signal in the hardware model, send signal from the primary clock to the clock input of the clock edge register in the hardware model via the gated clock logic, send a clock enable signal to the enable input of the hardware model""s register, send data from the primary clock register to the hardware model""s register via the gated data logic, and reset the clock edge register disabling the clock enable signal to the enable input of the hardware model""s registers; (9) log selective data for debug sessions and post-simulation analysis; (10) combinational logic regeneration; (11) in one embodiment, a basic building block is a D-type register with asynchronous inputs and synchronous inputs; (12) address pointers in each chip; (13) multiplexed cross chip address pointer chain; (14) array of FPGA chips and their interconnection scheme; (15) banks of FPGA chips with a bus that tracks the performance of the PCI bus system; (16) FPGA banks that allow expansion via piggyback boards; and (17) time division multiplexed (TDM) circuit for optimal pin usage. The present invention, through its various embodiments, provides other features as discussed herein, which may not be listed in the above list of features.
One embodiment of the present invention is a simulation system. The simulation system operates in a host computer system for simulating a behavior of a circuit. The host computer system includes a central processing unit (CPU), main memory, and a local bus coupling the CPU to main memory and allowing communication between the CPU and main memory. The circuit has a structure and a function specified in a hardware language, such as HDL, which is capable of describing the circuit as component types and connections. The simulation system includes: a software model, a software control logic, and a hardware logic element.
The software model of the circuit is coupled to the local bus. Typically, it resides in main memory. The software control logic is coupled to the software model and the hardware logic element, for controlling the operation of the software model and the hardware logic element. The software control logic includes interface logic that is capable of receiving input data and a clock signal from an external process, and a clock detection logic for detecting an active edge of the clock signal and generating a trigger signal. The hardware logic element is also coupled to the local bus and includes a hardware model of at least a portion of the circuit based on component type, and a clock enable logic for evaluating data in the hardware model in response to the trigger signal.
The hardware logic element also comprises an array or plurality of field programmable devices coupled together. Each field programmable device includes a portion of the hardware model of the circuit and thus, the combination of all the field programmable devices includes the entire hardware model. A plurality of interconnections also couple the portions of the hardware model together. Each interconnection represents a direct connection between any two field programmable devices located in the same row or column. The shortest path between any two field programmable devices in the array is at most two interconnections or xe2x80x9chops.xe2x80x9d
Another embodiment of the present invention is a system and method of simulating a circuit, where the circuit is modeled in software and at least a portion of the circuit is modeled in hardware. Data evaluation occurs in the hardware but is controlled in software via a software clock. Data to be evaluated propagates and stabilizes to the hardware model. When the software model detects an active clock edge, it sends an enable signal to the hardware model to activate data evaluation. The hardware model evaluates the data and then waits for the new incoming data that may be evaluated at the next active clock edge signal detection in the software model.
Another embodiment of the present invention includes a software kernel that controls the operation of the software model and the hardware model. The software kernel comprises the steps of evaluate active test-bench processes/components, evaluate clock components, detect clock edge, update registers and memories, propagate combinational components, advance simulation time, and continue the loop as long as active test-bench processes are present.
A further embodiment of the present invention is a method of simulating a circuit, where the circuit has a structure and a function specified in a hardware language, such as HDL. The hardware language is also capable of describing or reducing the circuit into components. The method steps comprise: (1) determining component type in the hardware language; (2) generating a model of the circuit based on component type; and (3) simulating the behavior of the circuit with the model by providing input data to the model. Generating the model may include: (1) generating a software model of the circuit; and (2) generating a hardware model of the circuit based on component type.
In another embodiment, the present invention is a method of simulating a circuit. The steps include: (1) generating a software model of the circuit; (2) generating a hardware model of the circuit; (3) simulating a behavior of the circuit with the software model by providing input data to the software model; (4) selectively switching to the hardware model; (5) providing input data to the hardware model; and (6) simulating a behavior of the circuit with the hardware model by accelerating the simulation in the hardware model. The method may also include the additional steps of: (1) selectively switching to the software model; and (2) simulating a behavior of the circuit with the software model by providing input data to the software model. The simulation can also be stopped with the software model.
For the in-circuit emulation mode, the method comprises: (1) generating a software model of the circuit; (2) generating a hardware model of at least a portion of the circuit; (3) providing input signals from the target system to the hardware model; (4) providing output signals from the hardware model to the target system; (5) simulating a behavior of the circuit with the hardware model, where the software model is capable of controlling the simulation/emulation, cycle by cycle.
For the post-simulation analysis, the method of simulating a circuit comprises: (1) generating a model of the circuit; (2) simulating a behavior of the circuit with the model by providing input data to the model; and (3) logging selective input data and selective output data as log points from the model. A software and hardware model can be generated. The method may further comprise the steps of: (1) selecting a desired time-dependent point in the simulation; (2) selecting a log point at or prior to the selected time-dependent point; (3) providing input data to the hardware model; and (4) simulating a behavior of the circuit with the hardware model from the selected log point.
A further embodiment of the present invention is a method of generating models for a simulation system for simulating a circuit. The steps include: (1) generating a software model of the circuit; (2) generating a hardware model for at least a portion of the circuit based on component type, said component type including register components and combinational components; and (3) generating a clock generation circuit in the hardware model to trigger data evaluation in the hardware model in response to clock edge detection in the software model.
The coverification system and method of processing and routing data therein in accordance with one embodiment of the present invention provide solutions to the problems mentioned above. The coverification system provides a powerful and flexible design tool that allows the software design to be simulated and verified on the hardware design prior to fabrication of the hardware design as an ASIC and with more flexibility than that provided by a conventional emulator. Additionally, the coverification system is uniquely positioned to support the paradigm shift of integrating hardware designers with software designers for a given project and moving the verification step further up in the design stage.
One embodiment of the present invention is a coverification system that includes a reconfigurable computing system (hereinafter xe2x80x9cRCC computing systemxe2x80x9d) and a reconfigurable computing hardware array (hereinafter xe2x80x9cRCC hardware arrayxe2x80x9d). In some embodiments, the target system and the external I/O devices are not necessary since they can be modeled in software. In other embodiments, the target system and the external I/O devices are actually coupled to the coverification system to obtain speed and use actual data, rather than simulated test bench data. The RCC computing system contains a CPU and memory for processing data for modeling the entire user design in software. The RCC computing system also contains clock logic (for clock edge detection and software clock generation), test bench processes for testing the user design, and device models for any I/O device that the user decides to model in software instead of using an actual physical I/O device. Of course, the user may decide to use actual I/O devices as well as modeled I/O devices in one debug session.
The software clock is provided to the external interface to function as the external clock source for the target system and the external I/O devices. The use of this software clock provides the synchronization necessary to process incoming and outgoing data. Because the RCC computing system-generated software clock is the time base for the debug session, simulated and hardware-accelerated data are synchronized with any data that is delivered between the coverification system and the external interface.
The RCC hardware array contains the hardware model of the user design. During the design and programming of the user design, the RCC computing system can deliver configuration information to the RCC hardware array so that the hardware model is programmed in the various reconfigurable logic elements (e.g., FPGA chips). Thus, during the debug session, the user can simulate any part of his design, accelerate any part of his design to any test point using the hardware model, inspect internal register and combinational component values in the hardware model, step through various test points cycle-by-cycle as necessary. Various workstations can be connected to the coverification system to allow different users access to the user design based on a round-robin time sharing scheme.
When the target system and the external I/O devices are coupled to the coverification system, pin-out data must be provided between the coverification system and its external interface. After all, if the user design is some peripheral device that is part of some computing environment, the coverification system must provide the means necessary to allow communication between the user design and both the target system (e.g., operating system or some target application) and other I/O devices. For example, if the user design is a video controller, it must communicate with the CPU in the target system as well as a monitor.
The coverification system contains a control logic that provides traffic control between: (1) the RCC computing system and the RCC hardware array, and (2) the external interface (which are coupled to the target system and the external I/O devices) and the RCC hardware array. Because the RCC computing system has the model of the entire design in software, including that portion of the user design modeled in the RCC hardware array, the RCC computing system must also have access to all data that passes between the external interface and the RCC hardware array. The control logic ensures that the RCC computing system has access to these data.
The data that passes among the RCC computing system, the RCC hardware array, and the external interface (i.e., target system and external I/O devices) are pin-out data. The target system and the external I/O devices have their own pin-outs. The hardware model in the RCC hardware array has pin-outs as well. For example, if the user design is a CRTC 6845 video controller, some representative pin-outs would be DE (i.e., display enable), VS (i.e., vertical synchronization), HS (i.e., horizontal synchronization), MA0-MA13 (i.e., memory address), and D0-D7 (i.e., data bus). These pin-outs in the hardware model are provided in the RCC hardware array during hardware model configuration time as internal nodes in various reconfigurable logic elements.
The data-in portion of the control logic uses two types of data cyclesxe2x80x94a global cycle and a software-to-hardware (S2H) cycle. The global cycle is used for any data that is directed to all the chips in the RCC hardware array such as clocks, resets, and some other software-to-hardware (S2H) data directed at many different internal nodes in the RCC hardware array. For these latter xe2x80x9cglobalxe2x80x9d S2H data, it is more feasible to send these data out via the global cycles than the sequential S2H data.
The software-to-hardware cycle is used to send data from the test bench processes in the RCC computing system to the RCC hardware array sequentially from one chip to another in all the boards. Because the hardware model of the user design is distributed across several boards, the test bench data must be provided to every chip for data evaluation.
During these two cycles, the actual latching of data at these internal nodes are accomplished by global pointers (i.e., GLB_PTRx) and S2H_PTRx in each reconfigurable logic element. During the global cycle, the coverification system sends global data from the RCC computing system to the RCC hardware array and the clock logic. Then, the coverification system sends global data from the external interface to the RCC hardware array (and various internal nodes by activating various pointers) and an external buffer. The RCC computing system can access these global data arriving from the external interface by accessing the external buffer. During the S2H cycle, the coverification system sends data from the RCC computing system and test bench processes to the RCC hardware array sequentially; that is, the data is delivered to the RCC hardware array one chip at a time in each board (to various internal nodes by activating various S2H pointers).
In contrast to the two cycle types of the data-in cycles, the data-out cycle includes only one type of cycle. The data-out control logic requires that the data from the RCC hardware model be sequentially delivered to: (1) the RCC computing system, and then (2) the RCC computing system and the external interface (to the target system and the external I/O devices). Specifically, the data-out cycle requires that data from the internal nodes of the hardware model in the RCC hardware array be delivered to the RCC computing system first, and then to the RCC computing system and the external interface second in each chip, one chip at a time in each board and one board at a time. This is also accomplished with the aid of hardware-to-software (H2S) pointers. Whatever data in the internal nodes of the hardware model that was meant to be delivered to the RCC computing system (because an I/O device is modeled in software in the RCC computing system) will reach the RCC computing system. Whatever data in the internal nodes of the hardware model that was meant to be delivered to the external interface will reach the external interface as well as the RCC computing system.
These and other embodiments are fully discussed and illustrated in the following sections of the specification.